home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1992 / f / f420.asc < prev    next >
Text File  |  1994-01-31  |  46KB  |  1,092 lines

  1.  
  2.  
  3.  
  4. Recommendation F.420
  5.                                  
  6.                      MESSAGE HANDLING SERVICES:
  7.             THE PUBLIC INTERPERSONAL MESSAGING SERVICE
  8.  
  9.      The establishment in various countries of message handling
  10. services in association with public networks creates the need to
  11. produce Recommendations covering the aspects of public message
  12. handling services.
  13.  
  14.      The CCITT,
  15.  
  16. considering
  17.  
  18.      (a)   the need for public message handling services;
  19.  
  20.      (b)   the strategic and commercial importance of
  21. standardization of message handling services;
  22.  
  23.      (c)   the urgent need for intercommunication agreements for
  24. existing telematic services, and other services with public message
  25. handling services;
  26.  
  27.      (d)   the need for a clear distinction between the
  28. responsibilities to be allocated to service providers and those of
  29. subscribers and/or users;
  30.  
  31.      (e)   the need for establishing international compatibility
  32. between different messaging systems;
  33.  
  34.      (f)   the growth of the installed base of terminals and
  35. personal computers with the ability to access message handling
  36. systems;
  37.  
  38.      (g)   that several F-series Recommendations describe public
  39. message handling services;
  40.  
  41.      (h)   that certain X and T-series Recommendations cover
  42. relevant aspects of systems used for the provision of messaging
  43. services,
  44.  
  45. unanimously declares
  46.  
  47.      the view that the requirements specified in this
  48. Recommendation should be applied for the provision of the public
  49. interpersonal messaging service internationally.
  50.                                  
  51.                              CONTENTS
  52.                                  
  53.  
  54. 1    Purpose and scope
  55.      1.1  General
  56.      1.2  Message handling systems used in the provision of IPM
  57.         service
  58.  
  59. 2    IPM service
  60.      2.1  General service requirements
  61.      2.2  IPM service features
  62.      2.3  Responsibility boundaries
  63.      2.4  Message service
  64.      2.5  Use of directory
  65.      2.6  Security
  66.      2.7  Distribution lists
  67.      2.8  Intercommunication with physical delivery services
  68.  
  69. 3    Types of body parts
  70.  
  71. 4    Conversion between different encoded information types
  72.  
  73. 5    Naming and addressing in general
  74.      5.1  Directory names
  75.      5.2  O/R names
  76.      5.3  O/R addresses
  77.  
  78. 6    Operation of the service
  79.      6.1  General
  80.      6.2  Message handling phases
  81.  
  82. 7    Quality of service
  83.      7.1  Message status
  84.      7.2  Support by Administrations
  85.      7.3  Model of delivery and notification times
  86.      7.4  Message delivery time targets
  87.      7.5  Delivery notification time targets
  88.      7.6  Receipt notifications and non-receipt notifications
  89.      7.7  Error protection
  90.      7.8  Availability of service
  91.      7.9  Minimum storage capacity
  92.  
  93. 8    Tariff and accounting principles
  94.  
  95. 9    Network requirements
  96.  
  97. 10   User information and support
  98.  
  99. 11   Use of the IPM service within CCITT-defined telematic services
  100.  
  101. Annex A -  Abbreviations
  102.  
  103. Annex B -  Subscriber access and terminal requirements
  104.  
  105. Annex C -  IPM service elements from 1984 X.400 Recommendations
  106.  
  107.  
  108. 1    Purpose and scope
  109.  
  110. 1.1  General
  111.  
  112.      This Recommendation specifies the general, operational and
  113. quality of service aspects of the public international
  114. interpersonal messaging service. interpersonal messaging services
  115. provided by Administrations belong to the group of telematic
  116. services defined in the F-series Recommendations.
  117.  
  118.      This type of message handling service is an international
  119. telecommunication service offered by Administrations, enabling
  120. subscribers to send a message to one or more recipients and to
  121. receive messages via telecommunication networks using a combination
  122. of store-and-forward, and store-and-retrieve techniques.
  123.  
  124.      Locally provided functions, for which communication with other
  125. subscribers is not required, are not covered by CCITT
  126. Recommendations.
  127.  
  128.      The Interpersonal Messaging (IPM) Service enables subscribers
  129. to request a variety of features to be performed during the
  130. handling and exchange of messages.
  131.  
  132.      Some features are inherent in the basic IPM service. Other non-
  133. basic features may be selected by the subscriber, either on a per-
  134. message basis or for an agreed contractual period of time, if they
  135. are provided by Administrations.
  136.  
  137.      Basic features have to be made available internationally by
  138. Administrations. Non-basic features, visible to the subscriber, are
  139. classified as either essential or additional. Essential optional
  140. features must be made available internationally by Administrations
  141. for national use and internationally on the basis of bilateral
  142. agreement. Non-basic features are called optional user facilities.
  143.  
  144.      IPM service may be provided using any physical network. IPM
  145. service may be offered separately or in combination with various
  146. telematic or data communication services. It can be obtained by
  147. making appropriate arrangements.
  148.  
  149.      Technical specifications and protocols, to be used in the IPM
  150. service are defined in the X.400-series Recommendations, in
  151. Recommendation T.330 and in Recommendation U.204.
  152.  
  153.      This service definition is contained in ñ 2. Requirements for
  154. intercommunication between subscribers are described in ññ 3 and 4.
  155. Section 5 describes naming and addressing, while ññ 6, 7 and 8
  156. describe the operation of the service, quality of service, tariff
  157. and accounting principles. Network requirements are given in ñ 9.
  158. The provision of subscriber information is in ñ 10, and ñ 11
  159. contains information on the use of IPM service within CCITT defined
  160. telematic services.
  161.  
  162. 1.2  Message handling systems used in the provision of IPM service
  163.  
  164. 1.2.11984 implementations
  165.  
  166.      This service Recommendation assumes that the message handling
  167. systems implemented to provide the service outlined herein are
  168. based on the 1988 version of the X.400-series Recommendations. It
  169. is recognized however that for some time after the publication of
  170. this Recommendation, the majority of implementations of IPM service
  171. will be based on the 1984 X.400-series of Recommendations.
  172. Administrations are encouraged to adopt the latest CCITT
  173. Recommendations; however, in the interim, they may make use of this
  174. Recommendation with 1984 implementations as outlined below.
  175.  
  176. 1.2.2Elements of service
  177.  
  178.      Elements of service available for message handling services
  179. are listed and classified in Recommendation F.400. Annex C provides
  180. a list of all the elements of service (called service elements in
  181. 1984) for IPM from the 1984 X.400 Recommendation. In addition, the
  182. classification of each element of service as they were in 1984 in
  183. Recommendation X.401 are shown. In the 1988 X.400 Recommendation,
  184. there are many new elements of service representing the new
  185. functionality that were not present in 1984. Most of these have
  186. been classified as additional, meaning that they do not have to be
  187. supported, hence the 1984 implementations can make use of this
  188. service Recommendation in most cases. Other differences between
  189. 1988 and 1984 are of two types, new elements of service that are
  190. classified as essential, and old (meaning 1984) elements of service
  191. that have been re-classified as essential for 1988. Annex C of
  192. Recommendation F.400 lists both the new elements of service in 1988
  193. as well as changes in classification to any 1984 elements of
  194. service. In both cases, to allow for 1984 implementations to be
  195. used for the provision of public IPM service as described in this
  196. Recommendation, a grace period of 8 years is provided for
  197. Administrations to upgrade their implementations in this respect to
  198. the 1988 technical Recommendations.
  199.  
  200. 1.2.3Name forms
  201.  
  202.      The specification of the name forms in the 1988
  203. Recommendations have been enhanced and postal O/R addresses have
  204. been added. The name forms and the mandatory components of the 1984
  205. Recommendations have their equivalence in the new framework and are
  206. aligned in principle.
  207.  
  208. 1.2.4Interworking
  209.  
  210.      In order to protect the investment of Administrations who have
  211. implemented 1984 systems for the provision of IPM service, 1988
  212. ADMD implementations shall be able to interwork to 1984 ADMDs as
  213. outlined in Recommendation X.419, Annex B.
  214.  
  215.      Interworking from 1988 ADMDs to 1984 PRMDs is a national
  216. matter.
  217.  
  218.  
  219. 2    IPM service
  220.  
  221. 2.1  General service requirements
  222.  
  223. 2.1.1   The fundamental ability of the IPM service is to provide a
  224. public interface between originators and recipients to enhance
  225. their means of communication especially where there is no immediate
  226. or convenient direct telecommunication service available between
  227. subscriber's equipment or the telecommunication services available
  228. are incompatible.
  229.  
  230.      This service may also provide features available for the
  231. preparation and the presentation of the messages.
  232.  
  233. 2.1.2   The IPM service will be provided by Administrations using
  234. the message transfer service defined in Recommendation F.410, and
  235. by systems that conform to the X.400-series of Recommendations.
  236.  
  237.      Management domains (MDs) are defined for the purpose of
  238. responsibility boundaries. The MD managed by an Administration is
  239. called an administration management domain (ADMD). The MD managed
  240. by an organization is called a private management domain (PRMD).
  241.  
  242. 2.1.3   International exchange of messages are performed between
  243. administration management domains through CCITT-standardized public
  244. data transmission services.
  245.  
  246. 2.1.4   Different body part types of messages may be exchanged
  247. through this service. The urgent body part types are listed in ñ 3.
  248.  
  249. 2.1.5   An Administration may provide subscribers with different
  250. methods of access to the IPM service. The possible methods are:
  251.      1)directly from the user's terminal;
  252.      2)via a private message handling system.
  253.  
  254. 2.1.6   Each Administration is responsible for the national access
  255. to its management domain.
  256.  
  257. 2.1.7   The characteristics of the interfaces and access methods
  258. used between terminals and the IPM service are a national matter,
  259. although they may follow various CCITT-standardized services such
  260. as telex, teletex, facsimile videotex or data transmission
  261. services. However, the IPM service optional user facilities offered
  262. are defined and are independent of the access method and user's
  263. terminal.
  264.  
  265. 2.1.8   The national implementation of the IPM service may provide
  266. intercommunication with existing services such as telex, teletex,
  267. facsimile and videotex. When implemented, the interfaces between
  268. the IPM and the other services shall be according to relevant CCITT
  269. Recommendations.
  270.  
  271. 2.1.9   As the service is providing indirect communication, cases
  272. of non-delivery of the message to the intended recipient may occur.
  273. The IPM service provides for non-delivery notification and, as
  274. optional user facilities, for delivery, receipt and non-receipt
  275. notifications.
  276.  
  277. 2.1.10  Due to the intermediate storage of the message, the service
  278. may provide conversion optional user facilities: speed, access
  279. procedures, networks, and coding of message contents.
  280.  
  281. 2.1.11  The message belongs to the originator until delivery has
  282. taken place. After delivery, the message belongs to the recipient.
  283.  
  284. 2.1.12  Where a sender and recipient have different and conflicting
  285. requirements, the sender's requirements shall take precedence
  286. (e.g., body type conversion or redirection control).
  287.  
  288. 2.2  IPM service features
  289.  
  290. 2.2.1Introduction
  291.  
  292.      Recommendation F.400, ñ 19, defines elements of service which
  293. are available in the IPM service and are classified as either
  294. belonging to the basic service or as IPM optional user facilities.
  295. Elements of service comprising the basic IPM service are inherently
  296. part of the service and are always provided and available. The
  297. optional user facilities that are classified as essential are
  298. always provided and those classified as additional may be available
  299. nationally, or internationally on the basis of bilateral agreement.
  300.  
  301. 2.2.2Basic IPM service
  302.  
  303.      A set of elements of service comprises the basic IPM service.
  304. This set is defined in Recommendation F.400, and listed in Table
  305. 10/F.400. The basic IPM service, which is built upon the MT
  306. service, enables a user to send and receive IP messages. A user
  307. prepares IP-messages with the assistance of his user agent (UA).
  308. User agents, which are a set of computer application processes,
  309. cooperate with each other to facilitate communication between their
  310. respective users. To send an IP-message, the originating user makes
  311. a request of his UA, specifying the name or address of the
  312. recipient who is to receive the IP-message. The IP-message, which
  313. has an identifier conveyed with it, is then sent by the
  314. originator's UA to the recipient's UA via the message transfer
  315. service.
  316.  
  317.      Following a successful delivery to the recipient's UA, the IP-
  318. message can be followed by the recipient. To facilitate meaningful
  319. communication, a receiving user may specify the encoded information
  320. type(s) that can be contained in IP-messages delivered to him, as
  321. well as the maximum length of a message he is willing to have
  322. delivered to him. The original encoded information type(s) and an
  323. indication of any conversions that may have been performed and the
  324. resulting encoded information type(s) are supplied with each
  325. delivered IP-messages. In addition, the submission time, delivery
  326. time and other capabilities are supplied with each IP-message. Non-
  327. delivery notification is provided with the basic services.
  328.  
  329. 2.2.3IPM optional user facilities
  330.  
  331.      A set of the elements of services of the IPM service are
  332. optional user facilities. The optional user facilities which may be
  333. selected on a per-message basis or for an agreed contractual period
  334. of time, are listed in Tables 11/F.400 and 12/F.400, respectively.
  335. Local user facilities may be usefully provided in conjunction with
  336. some of these user facilities.
  337.  
  338.      The optional user facilities of the the IPM service that are
  339. selected on a per-message basis are classified for both origination
  340. and reception by UAs. If an Administration provides the IPM service
  341. and offers these optional user facilities for origination by UAs,
  342. then a user is able to create and send IP-messages according to the
  343. procedures defined for the associated element of service. If an
  344. Administration provides the IPM service and offers these optional
  345. user facilities for reception by UAs, then the receiving UA will be
  346. able to receive and recognize the indication associated with the
  347. corresponding Element of Service and to inform the user of the
  348. requested optional user facility. Each optional user facility is
  349. classified as additional or essential for UAs from these two
  350. perspectives.
  351.  
  352.      Note - With the access protocol described in Recommendation
  353. T.330, teletex terminals are able to make use of the basic IPM
  354. service as well as of the optional user facilities provided by the
  355. message handling service.
  356.  
  357. 2.2.4Local functions
  358.  
  359.      The MHS may perform many local functions for its subscribers
  360. in addition to providing IPM features. For example, to assist
  361. subscribers in preparing and editing IP-messages, MHS may provide
  362. an editing capability. This editor could operate on a single line
  363. of text at a time, or it could permit the display and alteration of
  364. a page at a time. A subscriber may have to access MHS frequently to
  365. determine if new messages have arrived. Alternatively, the MHS
  366. could alert the subscriber when new messages have arrived (for
  367. example, by setting a message light on his telephone, or by his
  368. displaying on his desktop terminal the originator's name and
  369. subject of all unread messages or by computer-initiated voice
  370. indication).
  371.  
  372.      The MHS may provide local database controls to help the
  373. subscriber find previously received and filed IP-messages (for
  374. example, to find the message from Mr. Jones delivered sometime in
  375. August on the subject of teleconferencing). A subscriber on
  376. vacation may request the MHS to automatically forward all his IP-
  377. messages to his delegate, or define rules for which IP-messages
  378. should not be auto-forwarded (for example, personal messages).
  379.  
  380.      Local services such as those above, while perhaps utilizing
  381. some of the IPM features, do not require coordination or
  382. cooperation with other subscribers. Thus they do not impact the
  383. communication protocols associated with MHS. Therefore, local
  384. functions that may be provided by Administrations are outside the
  385. scope of CCITT.
  386.  
  387. 2.3  Responsibility boundaries
  388.  
  389.      The purpose of the MHS is to allow messages to be submitted
  390. for transfer to the destination and to be delivered to a UA/MS
  391. whose address is specified by the originator.
  392.  
  393.      A user interacts with his UA on the sending and on the
  394. receiving side. On his request, a message is submitted to the MTS.
  395. He is also able to retrieve a received message from his UA or MS.
  396.  
  397.      The responsibility for the message rests in the MHS when the
  398. originating user gives the command to send the message. The
  399. responsibility for a message is turned over to the receiving UA/MS
  400. after successful delivery. If the UA or MS is provided by an
  401. Administration, the responsibility for the message is taken over by
  402. the user when he reads the message.
  403.  
  404.      As a basic feature, a non-delivery notification is created by
  405. the MHS when delivery to the receiving UA/MS is not possible. The
  406. conditions applied to this criteria may also depend on optional
  407. user facilities, e.g. conversion prohibition. An originating user
  408. may, for a particular message, specifically request a delivery
  409. notification, and/or a receipt notification, and/or a non-receipt
  410. notification.
  411.  
  412.      In the case of telematic addresses or telex addresses,
  413. delivery takes place automatically when the message is transmitted
  414. to the receiving terminal. The responsibility of the MHS ends when
  415. the message is received by the terminal. After delivery to a
  416. document store, or a message store, responsibility turns over to
  417. the user after having read the message once. When leaving the
  418. message in the store, the responsibility will be defined by the
  419. service provider.
  420.  
  421.      Loss of information may occur through the process of
  422. conversion as long as the conversion is not explicitly prohibited
  423. by the originating user.
  424.  
  425.      The responsibility of messages transferred through MDs starts
  426. at the moment of entering the domain and ends when leaving the
  427. domain; however, a later audit must be possible.
  428.  
  429.      When an ADMD interacts with a PRMD, the ADMD takes
  430. responsibility for the actions of the PRMD which are related to the
  431. interaction. In addition to ensuring that the PRMD properly
  432. provides the MT service, the ADMD is responsible for ensuring that
  433. the accounting, logging, quality of service and other related
  434. operations of the PRMD are correctly performed. An ADMD acts as the
  435. naming authority for the associated PRMDs.
  436.  
  437. 2.4  Message store
  438.  
  439.      Administrations may optionally provide message store (MS) to
  440. permit delivery of messages so that the recipient's UA does not
  441. have to be on line continuously. This is described in
  442. Recommendation F.400, ñ 7.4. A message delivered to an MS is deemed
  443. delivered by MHS. Messages delivered to an MS can be retrieved by
  444. the recipient at his convenience and various optional user
  445. facilities can be provided to allow for retrieval for listing,
  446. fetching, and deletion of messages. When subscribing to an MS, all
  447. messages destined to the UA are delivered to the MS, and if the UA
  448. is on line, an alert will be sent to the UA (from the MS) to inform
  449. the user of the fact that a message just arrived.
  450.  
  451. 2.5  Use of directory
  452.  
  453.      By making use of directory systems, IPM users will be able to
  454. address recipients by using directory names or distribution list
  455. names, which are more user friendly than O/R addresses. The MHS
  456. will be able to access a directory system and find out the O/R
  457. address(es) corresponding to a given directory name or distribution
  458. list name, for delivery of a message. This capability is described
  459. in Recommendation F.400, ñ 14.
  460.  
  461. 2.6  Security
  462.  
  463.      Administrations may optionally provide security mechanisms as
  464. outlined in Recommendation F.400, ñ 15, to counter the various
  465. security threats mentioned. This capability relies on a Directory
  466. System storing certified copies of public keys for MHS users.
  467.  
  468. 2.7  Distribution lists
  469.  
  470.      A group whose membership is stored in the directory can be
  471. used as a distribution list (DL). The originator simply supplies
  472. the name of the list on submission of a message, and the MHS can
  473. obtain the directory names (and then the O/R addresses) of the
  474. individual recipients, by consulting the directory. Upon receipt of
  475. a message addressed to a distribution list, the recipient can
  476. determine through which DL the message arrived. An originator can
  477. prohibit the expansion of the distribution if one of the recipients
  478. specified refers to a distribution list. Recommendation F.400, ñ
  479. 14, outlines the full capabilities available to DL users.
  480.  
  481.      If a user unknowingly sends a message to a DL, he may incur
  482. charges for multiple deliveries that he was not expecting. Because
  483. of this, names of distribution lists should be indicative of the
  484. fact that what is being named is a DL. Owners of DLs should also
  485. insure that they respect a potential member's wishes about being a
  486. member and the rules of the country of the member that may prohibit
  487. inclusion without prior agreement.
  488.  
  489. 2.8  Intercommunication with physical delivery services
  490.  
  491.      The intercommunication with the physical delivery services is
  492. an optional capability of the IPM service that allows for the
  493. sending of a message from an IPM user to a recipient via physical
  494. means, such as the traditional postal service. To invoke the
  495. capability, the originating user shall use the requested delivery
  496. method element of service on submission of his message, specifying
  497. physical delivery. The message may be addressed using the postal
  498. O/R address, or the directory name of the intended recipient, in
  499. which case the MHS will consult the directory system to determine
  500. the postal O/R address, The use of MH/PD service intercommunication
  501. by IPM users is described in Recommendation F.415 and
  502. Recommendation F.400, ñ 10.
  503.  
  504.  
  505. 3    Types of body parts
  506.  
  507.      Messages sent and received in the IPM service can be composed
  508. of one or more body parts. Applicable body part types are defined
  509. in Recommendation X.420 and comprise the following:
  510.      - IA5 text,
  511.      - Voice,
  512.      - G3 facsimile,
  513.      - G4 class 1,
  514.      - Teletex,
  515.      - Videotex,
  516.      - Encrypted,
  517.      - Message (e.g., for a forwarded message),
  518.      - Mixed mode,
  519.      - Bilaterally defined,
  520.      - Nationally defined,
  521.      - Externally defined.
  522.  
  523.  
  524. 4    Conversion between different encoded information types
  525.  
  526.      The MTS provides conversion functions to allow IPM users to
  527. input messages in one encoded format, called encoded information
  528. type (EIT), and have them delivered in another EIT to cater to
  529. users with different terminal types. This capability is inherent in
  530. the IPM service, and increases the possibility of delivery by
  531. tailoring the message to the recipient's terminal capabilities. The
  532. EITs supported for the IPM service are defined in Recommendation
  533. X.420. IPM users have some control over the conversion process
  534. through various elements of service as described Recommendation
  535. F.400/Annex B. These include the ability for a user to explicitly
  536. request the conversion required or as a default to let the MTS
  537. determine the need for, and type of, conversion performed. Users
  538. also have the ability to request that conversion not be performed
  539. or that conversion not be performed if loss of information will
  540. result. The definition of loss of information is given in
  541. Recommendation X.408.
  542.  
  543.      When the MTS performs conversion on a message, it informs the
  544. UA to whom the message is delivered that conversion took place and
  545. what the original EIT was.
  546.  
  547.      The conversion process for IP-messages can be performed on
  548. specific body parts if they are present in a message. The general
  549. aspects of conversion and the specific conversion rules for
  550. conversion between different EITs in the IPM service are detailed
  551. in Recommendation X.408.
  552.  
  553.  
  554. 5    Naming and addressing in general
  555.  
  556.      In MHS, the principal entity that requires naming is the user
  557. (the originator and recipient of messages). In addition,
  558. distribution lists (DLs) have names for use in MHS. Users of MHS
  559. nad DLs are identified by O/R names. O/R names are comprised of
  560. directory names and/or O/R addresses, all of which are described in
  561. this section. Recommendation F.401 provides more detail on naming
  562. and addressing for public message handling services, including
  563. naming restrictions and responsibilities of Administrations.
  564.  
  565. 5.1  Directory names
  566.  
  567.      Users of MHS service, and DLs, may be identified by a name,
  568. called a directory name. A directory name has to be looked up in a
  569. directory to find out the corresponding O/R address. The structure
  570. and components of directory names is described in the X.500 series
  571. of Recommendations.
  572.  
  573.      A user may access a directory system directly to find out the
  574. O/R address of a user or O/R addresses of the members of a DL (both
  575. of which are outside the scope of these Recommendations). As an
  576. alternative, a user may use the directory name and have the MHS
  577. access the directory to resolve the corresponding O/R address or
  578. addresses automatically.
  579.  
  580.      Every MHS user or DL will not necessarily have a directory
  581. name, unless they are registered in a directory. As directories
  582. become more prevalent, it is expected that directory names will be
  583. the preferred method of identifying MHS users to each other.
  584.  
  585. 5.2  O/R names
  586.  
  587.      Every MHS user or DL will have an O/R name. An O/R name
  588. comprises a directory name, an O/R address, or both. The directory
  589. name unambiguously identifies an MHS user but not necessarily
  590. uniquely. The O/R addres uniquely identifies an MHS user.
  591.  
  592.      Either or both components of an O/R name may be used on
  593. submission of a message. If only the directory name is present, the
  594. MHS will access a directory to attempt to determine the O/R
  595. address, which it will then use to route and deliver the message.
  596. If the directory name is absent, it will use the O/R address, but
  597. will carry the directory name and present both to the recipient. If
  598. the O/R address is incorrect, it will then attempt to use the
  599. directory name as above.
  600.  
  601. 5.2  O/R addresses
  602.  
  603.      An O/R address contains information that enables the MHS to
  604. uniquely identify a user to deliver a message or return a
  605. notification to him. (The prefix ╥O/R╙ recognizes the fact that the
  606. user can be acting as either the originator or recipient of the
  607. message or notification in question).
  608.  
  609.      Various forms of O/R addresses are currently defined, each
  610. serving its own purpose. These forms and their purpose are as
  611. follows:
  612.      - Mnemonic O/R address: Provides a user-friendly means of
  613.         identifying users in the absence of a directory. It is also
  614.         used for identifying a distribution list.
  615.      - Terminal O/R address: Provides a means of identifying users
  616.         with terminals belonging to various networks.
  617.      - Numeric O/R address: Provides a means of identifying users
  618.         with numeric keypads.
  619.      - Postal O/R address: Provides a means of identifying
  620.         originators and recipients of messages and notifications,
  621.         for physical delivery.
  622.  
  623.      An O/R address is made up of a collection of information
  624. called attributes. These attributes as used in each of the O/R
  625. address forms above are detailed in Recommendation F.401.
  626.  
  627.      Management domains shall allow their users to originate
  628. messages using any of the above forms. The form in which names are
  629. input by or presented to the subscriber is a national matter (as
  630. for example the use of distribution lists or of friendly ways of
  631. identifying user agents).
  632.  
  633.      Each Administration is responsible for the unique
  634. identification of each user agent in its management domain.
  635.  
  636.  
  637. 6    Operation of the service
  638.  
  639. 6.1  General
  640.  
  641. 6.1.1   The IPM service provides that messages can be sent,
  642. transferred, delivered and received, using fully automatic
  643. procedures.
  644.  
  645.      Note - Manual receipt and sending of message can be provided
  646. in the case of interworking with postal systems.
  647.  
  648. 6.1.2   Messages are prepared in, sent from, and delivered to a
  649. memory. These memories are part of the User Agent/MS functionality
  650. and are under control of the subscriber.
  651.  
  652. 6.1.3   The transfer of messages between management domains will be
  653. in accordance to the message transfer service as described in CCITT
  654. Recommendation F.410.
  655.  
  656. 6.1.4   Each Administration providing the IPM service should
  657. validate the subscribers' identities, at the time of access.
  658.  
  659.      Note - Further study is needed in the case of auto-receipt.
  660.  
  661. 6.1.5   It is a national matter whether to allow private messaging
  662. systems to connect to the public IPM service, in order to allow
  663. users of these systems to exchange messages. If these
  664. interconnections are provided, they should take place between
  665. Administration management domains in accordance with CCITT
  666. Recommendations.
  667.  
  668. 6.1.6   When implicit conversion is provided by the Adminstration
  669. via the message transfer service, the message vill be converted if
  670. necessary, unless prohibited by the originator. The conversion will
  671. be in accordance to the rules specified in CCITT Recommendations
  672. X.408. See also ñ 4 of this Recommendation.
  673.  
  674. 6.1.7   Deferred Delivery shall be provided by the management
  675. domain of the originator, which is responsible for the storage of
  676. the message until the date and time specified for intended
  677. delivery. Therefore the element of service, deferred delivery,
  678. should not be used across international links.
  679.  
  680. 6.2  Message handling phases
  681.  
  682. 6.2.1General
  683.  
  684.      The IPM service has different message handling phases visible
  685. to the user.
  686.  
  687. 6.2.2Preparation phase
  688.  
  689.      In this phase, messages are prepared by making use of the User
  690. Agent functionality (e.g. editing and filing). The way in which
  691. these functions are performed is outside the scope of this
  692. Recommendation.
  693.  
  694. 6.2.3Sending phase
  695.  
  696.      In this phase, the originator may request the user agent or
  697. message store to send a prepared message to one or more recipients
  698. and to request certain optional user facilities.
  699.  
  700. 6.2.4Receipt phase
  701.  
  702.      In this phase, the subscriber can receive delivered messages
  703. and notifications from his user agent or message store. The receipt
  704. phase can be initiated by the service (auto-receipt) or by the
  705. subscriber for message reception. The operation of the user agent
  706. receiving messages is specified in Recommendation X.420.
  707.  
  708.      Subscribers using terminals without user agent functionality
  709. may registter for a contractual period of time during which they
  710. will receive delivered messages automatically from their user agent
  711. to a terminal, if the Administration provides for this alternative.
  712. Normally the user agent is called to receive incoming messages.
  713.  
  714.      In the case of auto-receipt, the MHS will initiate a call to
  715. the subscriber's terminal. In the other case, the subscriber shall
  716. initiate a call to the MHS at a time convenient to the subscriber.
  717.  
  718.      The body parts of the message will be received by the
  719. subscriber in the form in which the originator has sent it, unless
  720. conversion has been performed.
  721.  
  722.      For messages delivered to a teletex access unit,
  723. Recommendation T.330 defines the optional means by which the
  724. subscriber may receive or retrieve delivered messages.
  725.  
  726.      The indication of the optional user facilities requested by
  727. the originator are presented by the user agent to the recipient in
  728. a form convenient to him.
  729.  
  730.      Notifications: Four notifications can be received:
  731.      - non-delivery notification;
  732.      - delivery notification;
  733.      - receipt notification;
  734.      - non-receipt notification.
  735.  
  736.      Non-delivery notification is automatically originated by the
  737. MTS, while delivery notification, receipt and non-receipt
  738. notification depend on the action of the recipient. In the case of
  739. a message to a teletex terminal, (auto) receipt notification may be
  740. returned by the TTXAU.
  741.  
  742.  
  743. 7    Quality of service
  744.  
  745. 7.1  Message status
  746.  
  747.      The unique identification of each IP-message enables the
  748. system to provide information about, e.g., the status of an IP-
  749. message.
  750.  
  751.      In the event of system failure, all accepted and non-delivered
  752. messages should be traceable. If messages cannot be delivered, the
  753. originator must be informed by a non-delivery notification.
  754.  
  755. 7.2  Support by Administrations
  756.  
  757.      Administrations should provide assistance to their
  758. subscribers, with regard to non-delivery notifications not being
  759. received in due time, as far as public system components are
  760. concerned. Additional provision on support of status and tracing of
  761. messages may be provided under national responsibility.
  762.  
  763.      When the user agent is provided by an Administration,
  764. additional functionality should be provided in order to minimize
  765. cases of not reading messages within a certain period of time (the
  766. definition of this period is for further study). This functionality
  767. could be, for example, alert messages sent to an automatic
  768. reception terminal.
  769.  
  770. 7.3  Model of delivery and notification times (see Figure 1/F.420)
  771.  
  772. 7.4  Message delivery time targets
  773.  
  774.      The management domain of the recipient UA should force non-
  775. delivery notification if the message has not been delivered before
  776. x hours after submission (or after date and time indicated for
  777. deferred delivery), the value of x being dependent on the grade of
  778. delivery requested by the originator. (See Recommendation F.410, ñ
  779. 4.4.)
  780.  
  781. 7.5  Delivery notification time targets
  782.  
  783.      Non-delivery notifications or requested delivery notifications
  784. should be returned on a per-recipient basis, in order not to delay
  785. notifications for those messages in a multi-addressed message which
  786. have already been delivered, to enable the originating management
  787. domain either to return per-recipient notifications or to batch
  788. notifications to its subscribers. (See Recommendation F.410, ñ
  789. 4.5.)
  790.  
  791. 7.6  Receipt notifications and non-receipt notifications
  792.  
  793.      Delivery times for receipt or non-receipt notifications in the
  794. first place depend on local arrangements. When they are initiated
  795. by the receiving UA/user, they have the same time targets as the
  796. messages that cause them to occur (see Table 1/F.420).
  797.  
  798. 7.7  Error protection
  799.  
  800.      Error protection on transmission is provided by the MHS and
  801. underlying protocols used in the provision of the IPM service.
  802.  
  803. 7.8  Availability of service
  804.  
  805.      In principle, the IPM service should be available
  806. continuously. The user agent should be available for submission of
  807. delivery continuously (unless hold for delivery is invoked). In
  808. cases where the UA is not available for delivery continuously, a
  809. message store should be used.
  810.                                  
  811.                                  
  812.                                  
  813.                                  
  814.                           Figure 1/F.420
  815.                                  
  816.                                  
  817.                            TABLE 1/F.420
  818.                                          
  819.                     Grade of      95% delivered
  820.                   delivery (of        before
  821.                   the referred           
  822.                     message)
  823.                         
  824.                                          
  825.                 Urgent              0.75 hours
  826.                                          
  827.                                          
  828.                 Normal              4    hours
  829.                                          
  830.                                          
  831.                 Non-urgent         24    hours
  832.                                          
  833. Note - Intercommunication with PRMDs is not included in the
  834. calculation of the time targets.
  835.  
  836. 7.9  Minimum storage capacity
  837.  
  838.      The storage capacity of a user agent and message store shall
  839. be sufficient to provide a high grade of service.
  840.  
  841.      Note - This is for further study.
  842.  
  843.  
  844. 8    Tariff and accounting principles
  845.  
  846.      See D-series Recommendations.
  847.  
  848.  
  849. 9    Network requirements
  850.  
  851.      The IPM service is network independent, that is, the basic
  852. service and the essential optional user facilities are provided
  853. independently of the type of network used for service access.
  854. Additional optional user facilities chosen by an Administration to
  855. offer may vary.
  856.  
  857.  
  858. 10   User information and support
  859.  
  860.      A directory shall be provided by each Administration for its
  861. domain. The directory can be hard copy or preferably electronic
  862. form.
  863.  
  864.      The directory shall at least contain the following:
  865.      a)how to use the directory and the service;
  866.      b)list of O/R addresses of subscribers belonging to the
  867.         Administration's domain;
  868.      c)list of standardized abbreviations for O/R address
  869.         attributes;
  870.      d)list of country and Administration management domain names
  871.         reachable by the public IPM service.
  872.  
  873.  
  874. 11   Use of the IPM service within CCITT-defined telematic services
  875.  
  876.      See relevant F-series Recommendations.
  877.                                  
  878.                                  
  879.                                  
  880.                               ANNEX A
  881.                                  
  882.                      (to Recommendation F.420)
  883.                                  
  884.                            Abbreviations
  885.                                  
  886.  
  887.      The following abbreviations are used in this Recommendation.
  888.            A       Additional Optional User Facility
  889.            ADMD    Administration Management Domain
  890.            DL      Distribution List
  891.            E       Essential Optional User Facility
  892.            EIT     Encoded Information Type
  893.            G3      Group 3 (Facsimile)
  894.            G4      Group 4 (Facsimile)
  895.            IA5     International Alphabet 5
  896.            IP      Interpersonal
  897.            IPM     Interpersonal Messaging
  898.            MD      Management Domain
  899.            MHS     Message Handling System
  900.            MS      Message Store
  901.            MT      Message Transfer
  902.            MTA     Message Transfer Agent
  903.            MTS     Message Tranfer System
  904.            N/A     Not Applicable
  905.            O/R     Originator/Recipient
  906.            PD      Physical Delivery
  907.            PDN     Public Data Network
  908.            PDS     Physical Delivery System
  909.            PRMS    Private Management Domain
  910.            TTXAU   Teletex Access Unit
  911.            UA      User Agent
  912.  Note 1 - For a glossary of terms see Annex A to Recommendation
  913. F.400.
  914. Note 2 - For references see Recommendations F.400 and F.401.
  915.                                  
  916.                                  
  917.                                  
  918.                               ANNEX B
  919.                                  
  920.                      (to Recommendation F.420)
  921.                                  
  922.             Subscriber access and terminal requirements
  923.                                  
  924.  
  925. B.1  General
  926.  
  927.      Various types of terminals may be used for accessing the
  928. service. These terminals are functionally divided into two
  929. categories: those without user agent functionality, and those with
  930. user agent functionality. The telematic terminals assume a special
  931. user agent. Telex terminals belong to that first category.
  932.  
  933. B.2  Terminals without UA functionality
  934.  
  935.      Terminals in this category require additional functions to be
  936. provided by MHS to enable their participation in the IPM service.
  937.  
  938. B.2.1Telex terminals
  939.  
  940.      Telex terminals shall conform to the relevant technical
  941. Recommendations, and be based on the relevant service
  942. Recommendations.
  943.  
  944. B.2.2Teletex terminals
  945.  
  946.      Teletex terminals shall conform to Recommendations T.60 and
  947. T.61. Documents which are exchanged between teletex terminals and
  948. the IPM service shall be in conformance to Recommendation F.200.
  949.  
  950.      The access procedures for submission and delivery of documents
  951. shall conform to Recommendation T.330.
  952.  
  953.      Note - The use of the interactive session protocol for
  954. submission and delivery is for further study. The ability to
  955. provide IPM service for documents using teletex standardized
  956. options is for further study.
  957.  
  958. B.2.3Facsimile terminals
  959.  
  960.      Group 3 and Group 4 facsimile terminals should have access to
  961. the IPM service.
  962.  
  963.      Note - Access procedures are for further study.
  964.  
  965. B.2.4Videotex terminals
  966.  
  967.      These terminals shall conform to Recommendation F.300.
  968.  
  969.      Note - Access procedures are for further study. Eventual
  970. subset of Recommendation F.300 needs to be considered.
  971.  
  972. B.2.5IA5 terminals
  973.  
  974.      The IA5 terminals are terminals able to send and receive
  975. messages encoded by characters chosen from the International
  976. Alphabet No. 5 (Recommendation T.50). The access procedures shall
  977. be based on one of the applicable procedures specified in
  978. Recommendations X.20 to X.32. These procedures describe the
  979. possibility for access to PDNs for data transmission.
  980.  
  981.      Note - Additional procedures are for further study.
  982.  
  983. B.3  Terminals with UA functionality
  984.  
  985.      These terminals shall, as a minimum, have the capabilities to:
  986.      1)provide the capabilities to subscribers of the basic
  987.         features defined in ñ 2;
  988.      2)make use of the IPM protocol specified in Recommendation
  989.         X.420;
  990.      3)use the submission and delivery protocol specified in
  991.         Recommendation X.419;
  992.      4)use the remote operation procedures specified in
  993.         Recommendation X.419.
  994.  
  995.      These terminals shall be able to handle at least one EIT as
  996. defined in Recommendation X.408 (e.g., IA5, teletex, etc.).
  997.                               ANNEX C
  998.                                  
  999.                      (to Recommendation F.420)
  1000.                                  
  1001.        IPM service elements from 1984 X.400 Recommendations
  1002.                                  
  1003.                                              Classification
  1004.            Element of service    Basic          Optionnal
  1005.                                         Orginat  Recepti  Contrac
  1006.                                           ion      on      tual
  1007.            Access management               X                 
  1008.            Alternate recipient                      A        A
  1009.            allowed
  1010.            Alternate recipient                               A
  1011.            assignment
  1012.            Authorizing users               A        E        
  1013.            indication
  1014.            Auto-fowarded                   A        E        
  1015.            indication
  1016.            Blind copy                      A        E        
  1017.            recipient
  1018.            indication
  1019.            Body part                       A        E        
  1020.            encryption
  1021.            indication
  1022.            Content type            X                         
  1023.            indication
  1024.            Conversion                      E        E        
  1025.            prohibition
  1026.            Converted               X                         
  1027.            indication
  1028.            Cross referencing               A        E        
  1029.            indication
  1030.            Deferred delivery               E       N/A       
  1031.            Deferred delivery               A       N/A       
  1032.            cancellation
  1033.            Delivery                        E       N/A       
  1034.            notification
  1035.            Delivery time stamp     X                         
  1036.            indication
  1037.            Disclosure of other             A        E        
  1038.            recipients
  1039.            Expiry date                     A        E        
  1040.            indication
  1041.            Explicit conversion             A       N/A       
  1042.            Fowarded IP-message             A        E        
  1043.            indication
  1044.            Grade of delivery               E        E        
  1045.            selection
  1046.            Hold for delivery                                 A
  1047.            Implicit conversion                               A
  1048.            Importance                      A        E        
  1049.            indication
  1050.            IP-message              X                         
  1051.            identification
  1052.            Message                 X                         
  1053.            identification
  1054.            Multi-destination               E       N/A       
  1055.            delivery
  1056.            Multi-part body                 A        E        
  1057.            Non-delivery            X                         
  1058.            notification
  1059.            Non-receipt                     A        A        
  1060.            notification
  1061.            Obsoleting                      A        E        
  1062.            indication
  1063.            Original encoded        X                         
  1064.            information types
  1065.            indication
  1066.            Originator                      E        E        
  1067.            indication
  1068.            Prevention of non-              A       N/A       
  1069.            delivery
  1070.            notification
  1071.            Primary and copy                E        E        
  1072.            recipients
  1073.            indication
  1074.            Probe                           A       N/A       
  1075.            Receipt                         A        A        
  1076.            notification
  1077.            Registered encoded      X                         
  1078.            information types
  1079.            Reply request                   A        E        
  1080.            indication
  1081.            Replying IP-message             E        E        
  1082.            indication
  1083.            Return of contents              A       N/A       
  1084.            Sensitivity                     A        E        
  1085.            indication
  1086.            Subject indication              E        E        
  1087.            Submission time         X                         
  1088.            stamp indication
  1089.            Typed body              X                         
  1090.  
  1091.  
  1092.